PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.50

Text File | 1988-06-15 | 26.9 KB | 673 lines | [TEXT/ttxt]

18-Apr-88 06:45:13-PDT,28145;000000000000
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 18 Apr 88 06:44:48 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac15554; 18 Apr 88 9:40 EDT
Received: from relay.cs.net by RELAY.CS.NET id aa12389; 18 Apr 88 9:35 EDT
Received: from sdr.slb.com by RELAY.CS.NET id ab12362; 18 Apr 88 9:29 EDT
Date: Mon, 18 Apr 88 09:21 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #50
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Mon 18 Apr 88 09:20:48-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #50
To: Usenet-List: ;
Message-ID: <577358448.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Saturday, April 16, 1988       Volume 4 : Issue 50

Today's Topics:
     Re: Applecolor Monitor Jitters
     Re: New MF features (ApplicationMenu)
     Mac <-> Autocad
     Re: Universe, Universe II, and Breach
     Haunted hard disk (really tape backup peculiarity)
     Choosing closest-color-by-blending
     DAHandler and memory management
     MPW C bug, again!
     Re: Time Zone trouble...
     Re: What hard disks does A/UX support
     Re: Choosing closest-color-by-blending
     Re: Picking a Debugger
     Re: Floppies (made in the USA) (look for the union label)
     Vaccine seems disabled (BY A VIRUS?)
     TAMIL FONTS, anyone ?

----------------------------------------------------------------------

From: [e-mail] (Steve Ligett)
Subject: Re: Applecolor Monitor Jitters
Date: 7 Apr 88 13:25:12 GMT
Organization: Dartmouth College, Hanover, NH

Apple distributed a note about this to dealers (via AppleLink), it's
titled "SERVICE NOTICE MACINTOSH II RGB SHIMMER"  and dated 3/1/88.

It points the tech to his/her technical procedures for adjusting the
monitor, and mentions that replacement of the monitor logic board may be
required.

Also --

"Affected Units

Most of the units that exhibit shimmering should be corrected during the
90-day warranty period.  However, if the customer's unit is past the
warranty period, Apple is offering a repair extension program that will
reimburse the cost of adjusting the monitor.  The affected units are
within the serial number range listed below and are date-stamped on the
rear of the cover of the High-Res RGB Monitor 'July, August or September
1987'

    M0401      5015941 or below
    M0401Z     5002301 or below
    M0110PA    5019901 or below
    M0401X     5000601 or below"

--
   Steve Ligett     [e-mail] or
(decvax harvard ihnp4 linus)!dartvax!steve.ligett


------------------------------

From: [e-mail] (Tony Jacobs)
Subject: Re: New MF features (ApplicationMenu)
Date: 8 Apr 88 15:14:39 GMT
Organization: University of Utah ME Dept

ApplMenu has one problem, when you hold down the command key you can
click anywhere in the menu to access it.  This is a conflict with
Hypercard! You cannot access the protection mechanisms because you need
to hold down the command key to do it!!!

I would like to see an addition to ApplMenu that allows you to quit
programs without having to go to them first. Something like holding down
the shift key when selecting the application from the ApplMenu.  The
reasons for this are that often I have to go quit an application in
order to open up another one. When you quit an application it will then
go to some other application in the list.  If this happens to be one
with a complex window it has to draw it may take a lone time to update
it and thus it slow down the process of opening up the new application.
Perhaps adding the ability to quit from the ApplMenu won't take you back
to the Finder or where ever you were last but it would help if it did.
--
Tony Jacobs * Center for Engineering Design * U of U * [e-mail]


------------------------------

From: [e-mail] (Greg Corson)
Subject: Mac <-> Autocad
Date: 7 Apr 88 00:36:58 GMT
Organization: Math. Dept., Univ. of Notre Dame

Anyone know of any drawing packages for the Mac that can write output
usable by Autocad?  I don't need full autocad functionality, even
something as simple as Mac-Draw would be ok.  I just need Autocad
compatable output.

The use is to do quick sketches of simple electrical wireing or physical
cabinet layouts which will then be transfered to our  professional
drafting people and their full blown Autocad system for cleanup and
plotting.

Please reply via USENET mail if possible...I can't always get in to read
this newsgroup.
--
Greg Corson
19141 Summers Drive
South Bend, IN 46637
[phone] (weekdays till 6 PM eastern)
{pur-ee,rutgers,uunet}!iuvax!ndmath!milo



------------------------------

From: [e-mail] (Paul Meyer)
Subject: Re: Universe, Universe II, and Breach
Date: 8 Apr 88 19:34:50 GMT
Organization: Cadnetix Corp.,  Boulder, CO

    I now own Universe for the Apple ][, Universe II for the Mac, and
Breach for the Mac.

    First, comments on the Universes:  both of these games have good ideas
and interesting plots and mechanics--you travel around in your starship,
combining trade, mining, and orbital piracy in some combination to keep
yourself financially solvent while involved in your real task.  In both
games the starship simulation is good enough to hold your interest even
without the added quest--especially in U1 where you are trying to pay
off the mortgage on your ship.
    Now for the bad news:  in both cases the implementation has problems.
In Universe 1 I never even SAW the quest because the game-time counter
NEVER INCREMENTED.  I wandered around trading and getting a better and
better ship, but I NEVER GOT ANY VIDCOMM MESSAGES OR ANY OTHER CLUES.
My old Apple ][+ died before I got to the stage of just looking around
all the out-of-the-way start systems for the Booster.
    My complaint about U2 is not as basic, but is even more fatal: from the
behavior of the code and the fact that the resource management mechanism
of the Mac is NOT EVEN USED beyond what is necessary to load executable
code segments, it is clear that U2 wasn't designed to be easily
portable, IT WAS DESIGNED TO NOT NEED PORTING AT ALL.  It seems to have
been developed in UCSD Pascal for a "generic" environment, with no
effort at all given to making use of different machines' strengths and
avoiding their weaknesses.  As a result, it runs SLOW, SLOW, SLOW on the
Mac.  Different modes are entered, not by loading a new segment and
continuing, but by chaining to a new executable, re-initializing the
entire OS each time.  The menus are not drawn by loading a resource, but
by individually adding each menu title and item.  As a result it takes
many seconds to switch from, say, the main menu to the navigation
section.
    Thus, even though the plot was thickening and I was really interested
in the quest, I quit playing the game.  I really wanted to go out and
capture a Dagger-class marauder, but I couldn't stand the idea of
playing for a half-hour or more just to move from one planet to the
next.  I got very tired of not having the keyboard shortcuts for the
menu items the way I wanted them and not being able to change the
resources to fix it.  I gave up, not because I didn't like the game, but
because I couldn't get to it through all the poor implementation.

    I recently overcame this bad experience enough to buy Omnitrend's
newest Mac product, Breach.  This is a very different game, a tactical
game of science fiction commando action.  After ten or so hours of
playing it, I still like it.  I was frustrated at the lack of any
keyboard shortcuts, but this was a minor thing because the main part of
the game is so mouse-driven.  (The menus are used only for administrivia
like saving and restoring games...of course, I'd like to be able to type
command-O <filename> instead of pulling down a menu, moving my hand to
the keyboard, then typing <filename>.)  The use of the Mac operating
system is more sophisticated, but not perfect.  The only remaining
artifact of overportability is in the size of scenarios:  there are
absolute, and far too small, limits on the numbers of opponents and
objects (which include all your soldiers' equipment except their guns,
as well as all prisoners to be rescued and all datapacks to be
recovered).
    The documentation also suffers from overportability in one annoying
respect:  like games such as recent Ultimas and the Bard's Tales, the
manual is non-system-specific.  Unlike the others I mention, the
machine-specific stuff is NOT included on a separate reference card--it
is simply omitted.  This means there are NO SCREEN PICTURES and NO
DIAGRAMS OF WHAT TERRAIN TYPES AND OBJECTS LOOK LIKE. Playing the third
scenario that comes with the game, I found myself trying to pick up
every piece of machinery on the map because I didn't know what a
datapack looked like (though once I'd found one I understood it
immediately--it looked like a disk).
    One of the best things about Breach is the Scenario Builder--after
you've played some of their canned scenarios, you can begin creating and
trading your own.  This is where the limits on opponents and objects get
irritating.  I started a medium-sized scenario, based on a situation in
a popular SF book already treated in a wargame.  I laid out most of the
terrain and enemy base, and went back to put in the guards and base
population.  Oops, more than 40 enemies already!  I hadn't even gotten
to where 2/3 of the prisoners were to be!  I laid out the soldier's
starting equipment and started placing some supplies to be raided from
the enemy base, and oops, more than 30 objects at the point where I
started to place the first third of the prisoners!  D**n!

    Overall recommendations:
        Universe:  (if it's still available)
        game: 7/10; Apple implementation: 7/10

        Universe II:
        game: 8/10; Mac implementation: 3/10

        Breach:
        game: 8/10; Mac implementation: 9/10
--
Paul Meyer                      [e-mail]
Cadnetix Corp.
5775 Central Ave.               {uunet,boulder}!cadnetix!pem
Boulder, CO 80301               [phone]x244


------------------------------

From: [e-mail] (Jay Freeman)
Subject: Haunted hard disk (really tape backup peculiarity)
Date: 9 Apr 88 00:33:53 GMT
Organization: SPAR - Schlumberger Palo Alto Research


I have found an apparant peculiarity of the tape backup software that
comes with the Apple 40SC Tape Backup system, knowledge of which might
save users a little time and a few tape cartridges.  (I hope I have this
one figured out, perhaps some Apple net-watcher will correct me if I am
wrong.)

Briefly, I think that the "Backup Volume" command backs up entire tracks
at a time, and either (a) (of course!) backs up every track that has
undeleted data in any sector (even if most of the track is full of
deleted data) or (b) backs up every track from track 0 up to and
including the highest-numbered track that has any undeleted data in any
sector (even if some tracks in between contain nothing but deleted
data).

The impact here is that if your undeleted files are scattered around on
your hard disc (for example, if you have just deleted several megabytes
of temporary files), the "Backup Volume" command will write to tape many
more bits than there is valid data on your disk; thereby taking more
time and perhaps using more tape cartridges than would otherwise be
necessary.

The work-around is to do a complete "Backup Files", reformat the hard
disk, and then "Restore Files".

My evidence for this phenomenon comes from my Mac II, which has an
(Apple) 80 MByte internal hard disc and the (Apple) 40SC Tape Backup
unit. Recently, with only 30 MBytes on the disc (as attested by "Get
Info"), I found that the tape backup software insisted on using two
cartridges for a volume backup.  The cartridges are supposed to be 38.5
MBytes, so that was puzzling, the moreso because I had just done a
complete files backup to one cartridge with no problem.  After trying
various interim hacks (reboot, rebuild desktop) to no avail, I decided
to reformat and restore the files. I thought it would be wise to make an
extra file backup before reformatting, and I did so using the same
cartridge that was not big enough for a volume backup -- even more
puzzling.  But after reformatting and restoring files, the volume backup
went onto one cartridge with no problem.  Furthermore, the amount of
time for the volume backup decreased to about 32 minutes (roughly right
for 30 MBytes), whereas before the software had interrupted the backup
and asked for a new cartridge after 38 minutes, when the backup was only
about 95 percent complete.

I had indeed just deleted many megabytes from my file system.  Based on
the speed of the volume backup, I conjecture it is a track-based backup,
and the hypothesis given at the start of this item follows.  (It's
really just conjecture.) (Incidentally, that's not a bad way for a
volume backup program to run; this posting is not a bug report, just a
description of an undocumented behavior.)

Anyhow, it looks as if occasional reformat/restore will speed up volume
backups.  Perhaps one of the commercial utilities that groups all of a
file's blocks close together on disk would do as well.

Other details:  I was running system 5.0 (ordinary finder -- not
multifinder), had recently reformatted the disk (for other reasons) with
<forgot name> version 1.5, that came with system 5.0, and was running
version 1.1 of the tape backup software.  I was running the tape backup
software off a floppy disc, with that floppy as the system disc, so both
the file and volume backup were indeed backing up the entire hard disc.
(File backup won't back up open files, like the active system file and
the tape backup program itself.)

As for the "haunted hard disc" header, well, obviously, any
manifestation of the previous existence of a deleted file is a ghost,
and obviously, a hard disk full of ghosts is haunted.  Right?  Right!
:-)


                    -- Jay Freeman

<canonical disclaimer, these are my opinions only>


------------------------------

From: [e-mail] (Dave Platt)
Subject: Choosing closest-color-by-blending
Date: 8 Apr 88 22:03:27 GMT
Organization: Coherent Thought Inc., Palo Alto CA

Howdy.  I'm not sure whether this question is going to fall into the "10
standard beginners' questions that arise every two months" category
that's been getting so much discussion in comp.graphics... but what the
heck, I'll ask it anyhow.

                Background

I'm working on a Mac II application that draws on the screen in color.
Currently, the colors are program-specified, but I plan to add a Color
Picker routine to permit the user to choose any of the colors supported
by Color QuickDraw.  The underlying color specifications are 48-bit
(R,G,B) triplets, with each value being specified to 16 bits precision;
the actual video card supports only 8 bits of precision per color plane,
I believe.

I'd like to be able to generate reasonably-accurate hardcopy printouts
of the screen, using an ImageWriter II with a color ribbon.  The IW II
supports the old-style Macintosh color model (8 specific colors,
including black and white), but the printer driver doesn't know how to
map Color QuickDraw 48-bit color specifications into the 8-color model.

In the images that I'm generating (Mandelbrot fractal zooms), there are
some fairly large areas of uniform color.  I'd like to use a
color-dithering technique in these areas... printing pixels of different
colors (chosen from those available on the ribbon) so that the overall
color of the area matches the color chosen by the user as closely as is
practical.  The Mac II's Color QuickDraw supports a technique like this
for drawing within a color window;  one supplies an (R,G,B) color as
input, and receives in return a colored "brush" (a pattern of 8*8
pixels).  Within the "brush", each 2*2 square of pixels can combine up
to 4 of the colors available in the window's color table, with the
"average" color falling reasonably close to the (R,G,B) input color.

Unfortunately, this capability necessitates that one have a window
available whose color table contains only those colors actually
available for drawing.  Printing isn't performed via a color window...
it uses an old-style 1-bit-deep GrafPort, and the Color QuickDraw
routines won't work with it.  So, I'll need to construct such a colored
brush myself.

                 The Problem

Given a color palette of N colors, each of whose (R,G,B) values are
known to a reasonable precision, select a group of 4 of those N colors,
such that the average of these 4 colors' (R,G,B) values falls close to a
specified (R',G',B') color.

                 Techniques

Apple's documentation doesn't go into any great detail about the
algorithm that Color QuickDraw uses to make its choice of colors. Apple
does state that the algorithm was chosen for speed and reasonable
accuracy, and may not always produce the closest match to the desired
color.  I've read a report that the algorithm sometimes doesn't even
product an exact match when the desired color is one that happens to be
in the window's color table... the brush-maker constructs a two-color
brush rather than returning a solid brush of the desired color.

I have a vague suspicion that finding the closest/best match may be a
"difficult" problem:  similar to the knapsack problem, and thus
NP-complete.  I'd rather not put an exponential-time algorithm in the
critical path of my code!

So... what approaches might I use to construct these colored brushes in
a way that will result in a reasonably close match between the desired
color and a mix of those available, and which won't chew up gobs of
processor time?

  [Of course, one could make a good case that even an expensive brush-
   blending phase will be a relatively small task compared with
   generating a full-screen Mandelbrot image]

Thanks in advance for any suggestions, pointers to good references, etc.
 that any of you can make!  And, apologies if this turns out to be a
"bonehead Graphics-for-Gradeschoolers" problem that has been discussed
aleph-null times before.

--
Dave Platt                                             VOICE: [phone]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303
  UUCP: ...!{ames,sun,uunet}!coherent!dplatt     DOMAIN: [e-mail]
  INTERNET:   coherent![e-mail],    [e-mail],    [e-mail]


------------------------------

From: [e-mail] (D. Ranson CNET)
Subject: DAHandler and memory management
Date: 7 Apr 88 07:05:52 GMT


A friend of mine is a DA developper, and is experiencing many
difficulties with DAs under Multifinder, running in the DAHandler
partition. The problems seem related to memory management:
 - Cut and paste of large clipboards (4K on a 1M Mac+) is impossible.
 - NewPtr and NewHandle do not always return nil when the memory is not
available (!).

The same DAs have been tested running in the partition of a simple DA
shell application (by opening the DA with the option key down). In this
setup, all memory related problems disappear.

   Is this a bug in the DAHandler?

       Daniel Ranson
       ...!mcvax!inria!crcge1!ranson


------------------------------

From: [e-mail] (Larry Hutchinson)
Subject: MPW C bug, again!
Date: 8 Apr 88 16:42:58 GMT
Organization: Tektronix Inc., Beaverton, Or.


Just when you thought it was safe to add!  An old bug that was
supposedly fixed in MPW C ver 2.0.2 turns out to have only been wounded.

The following is the shortest program that I have found that exibits the
problem:


    main(argc,argv)
        int argc;
        char *argv[];
    {
        double    skuz[10];
        double    foo=4;

        skuz[5]= 2.3;
        skuz[5] += 4*foo;        /* this add fails */

        printf("skuz= %g\r",skuz[5]);
    }

The value printed is 2.3, which is the symptom of the old bug.  It is
just a little harder to make it appear now.

I am getting a little tired of this bug.  Does anyone know when MPW 3.0
is due out?  I am really looking forward to a whole new round of bugs.
--
Larry Hutchinson, Tektronix, Inc. PO Box 500, MS 50-383, Beaverton, OR 97077
UUCP:   [uunet|ucbvax|decvax|ihnp4|hplabs]!tektronix!tekgvs!larryh
ARPA:   [e-mail]
CSNet:  [e-mail]

PS
No, I haven't reported the bug to Apple.
(excuse: I don't have a modem and would procrastinate anyway.)


------------------------------

From: [e-mail] (Vicki Brown)
Subject: Re: Time Zone trouble...
Date: 8 Apr 88 20:19:18 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]> [e-mail] (David Whitney) writes:
>A seperate problem I have is this: now that we are running on Daylight Savings,
>A/ux reports the time as one hour later than what the Mac says the time is.
>In order for me to have A/ux tell me accurately that it is 10 am, I must
>set the mac to 9 am. Why is this?

Why this is, is that the Mac OS has no notion of Daylight savings time,
while A/UX does.  So, from now through October, A/UX will add another
hour to your time (as shown in the control panel).  However, there is a
way to avoid this muddle.

When you start to boot A/UX, stop sash before the launch.  Change the
GMT bias (in the General dialogue box of the Parameters menu) to be one
hour less (i.e. -240 for East coast, -420 for Pacific coast).  This says
that the Macintosh time is now one hour closer to GMT (true at this time
of year). A/UX will not think you have moved closer to GMT, but will add
the extra hour because it is time for Daylight Savings.  You can check
the date in sash before booting.

Remember to change the GMT bias back again in October. Got it?

  - vicki
--
Vicki Brown
A/UX Engineering        [e-mail]

(all opinions are my own and do not necessarily reflect those of my employer)


------------------------------

From: [e-mail] (Stuart Schmukler)
Subject: Re: What hard disks does A/UX support
Date: 8 Apr 88 23:38:26 GMT
Organization: U Chicago Computation Center

In article <[e-mail]> [e-mail] (David G. Cantor)
writes:
>
>Can somebody tell me what (non-Apple) hard disks are supported by the
>current incarnation of A/UX.

I know that we at UofC (and people U. Minn.) have gotten the Rodime's to
work under A/UX as an A/UX only drive.  We have not been able to get a
Mac OS partition greater than Apple's on the the disk.

I have heard that some-one got a Jasime running.

In prinicple the 'dp' utility can deal with any type of hard drive. The
problems are:
    Configuring and loading the Eschatology parts of A/UX
    Loading the Eschatology parts of A/UX
    Configuring the Mac partition
    Loading the Mac partition and    making sure that the Mac OS respects the
partition
     (say during Erase Disk)

SaS

PS: Dealing with 'dp' is arcane. If I was clearer on the subject I'd
write it up. We found that you had to check the System Admin man pages
and the A/UX device drivers manual.


------------------------------

From: [e-mail] (Marc T. Kaufman)
Subject: Re: Choosing closest-color-by-blending
Date: 9 Apr 88 02:21:50 GMT
Organization: Stanford University

Try the following: Draw into an offscreen PixMap, using 8 colors (the
imagewriter CLUT) in a 4-bit deep Map.  While the offscreen device is
active, let Quickdraw generate the color pixpat, using the CLUT you have
provided.  This should yield 4-bit pixels with one bit each of R,G,B
(and one bit unused).

Save this PixMap, and scan it to the Imagewriter driver, doing a
SetForeColor every time the pixel value changes. (grubby, but it
probably will work).

[I posted this to mac.programmer only, as the comp.graphics people
probably have a better way :-)]

Marc Kaufman ([e-mail])


------------------------------

From: [e-mail] (Dan Allen)
Subject: Re: Picking a Debugger
Date: 9 Apr 88 18:22:23 GMT
Organization: Apple Computer Inc, Cupertino, CA

The standard debugger that Apple offers is MacsBug, an assembly-level
debugger originally written by Motorola in the late 70s.  Apple has
since completely rewritten it I suppose, but it is usually the most up
to date with various Macintosh system software.  The latest shipping
version of MacsBug is 5.5, which is where I turned over the sources to a
new Mr. MacsBug at Apple who has continued to improve it, with a version
6.0 in the works for MPW 3.0 later this year.

TMON is a good debugger too.  MacsBug and TMON have both been trading
features with each other to the point that they are both quite nice.

Jasik's The Debugger is quite large, but of course very comprehensive as
well.

A new MPW source level debugger will be coming also with MPW 3.0 later
this year.  It will be very large and will require multiple MB of RAM
and MultiFinder to use it most effectively.

So which debugger to get?  I'd recommend MacsBug, but then, I wrote
MacsBug.
--
Dan Allen
Author of MacsBug
(I stood on the shoulders of giants like Steve Capps...; I didn't write
it all)


------------------------------

From: [e-mail] (Scott R. Anderson)
Subject: Re: Floppies (made in the USA) (look for the union label)
Date: 10 Apr 88 19:11:23 GMT
Organization: Department of Physics, Emory University, Atlanta

In article <EWKCqVy00Xo=[e-mail]> [e-mail]
(Richard Siegel) writes:
>Do NOT use Scotch (3M) floppies!
>
>I don't know if Kodak is any good or if it's US made, but you might look into
>them.

You might also check out Nashua.  Again, I don't know if they are any
good or what sort of guarantee they have, but they are made in Nashua,
New Hampshire and are relatively cheap.
--
*                                     Scott Robert Anderson
  *      **                           gatech!emoryu1!phssra
   *   *    *    **                   phssra@emoryu1.{bitnet,csnet}
    * *      * *    * **
     *        *      *  * * * * * * * * * * * * * * * * * * * * * * * * * * * *


------------------------------

From: [e-mail] (Phil Hunt)
Subject: Vaccine seems disabled (BY A VIRUS?)
Date: 11 Apr 88 14:43:46 GMT
Organization: Digital Equipment Corporation

Hello,

Yes, I have been having troubles with Viruses too.  I installed Vaccine
and rebooted and sure enough it DID come up and say that something was
trying to write a nVIR resource to my system file.  I told it to DENY
access and it seemed to work, but now, NOTHING since that first message
has ever come from Vaccine!!  As others have mentioned, I have tried to
add resources to the SYSTEM file and actually modified stuff in the
system file using resedit.  I also have tried LS 'C' and actually let
something infect my system with the nVIR stuff.  Vaccine has never
complained (since that very first message).  Is it possible that Vaccine
has been infected??

Next I will try to move a new copy of Vaccine to my system folder and
reboot.. Som, you may not be as safe as you thought!!!

Phil Hunt


------------------------------

From: [e-mail] (Swami Devanbu)
Subject: TAMIL FONTS, anyone ?
Date: 11 Apr 88 18:21:38 GMT
Organization: AT&T Bell Laboratories, Murray Hill


Does anyone know of a TAMIL font for the MACINTOSH, along with
downloadable Postscript fonts ?

thanks.

Prem Deanbu
--
{.....allegra!prem}
[e-mail]
[e-mail]

[phone]

------------------------------

End of Usenet Mac Digest
************************
-------